Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/security/doc/clippings/911211-01

Internet Message Format | 1992-01-09 | 7.2 KB

Date: Wed, 11 Dec 1991 11:28:30 +0100
From: "(Alain Brossard EPFL-SIC/SII)" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Information: NIS and password security

   For those who missed it in alt.security, I reproduced
below a security warning on NIS.  After contacting Peter Lamb,
he provided me with a patch he got from Purdue originally,
I fixed it up, modified it a bit, added a man page and recompiled ypserv
>From the 4.1.1 sources.  Since I can't distribute the sources, I'm
making available (for those who trust me :-) the binaries on litsun:pub/yp.uu.
   It is a uuencoded version of ypserv.tar.Z which includes
sun[34]/ypserv, ypserv.8 and hosts.nis.5.  The file hosts.nis contains
a list of subnets and hosts which are allowed to connect to the
NIS server.  No other hosts will be able to get any maps (including
the password file!).

                    Alain Brossard
                    [e-mail]

In article <prl.691873839@iis>, [e-mail] (Peter Lamb) writes:
|> There have been a number of queries and some not completely accurate
|> information posted on this question. I'll try to summarise the problem and
|> suggested workarounds. None of the workarounds is particularly satisfactory,
|> and I'll try to give a reasonable summary of the pros and cons.
|>
|> The problem is this: ypserv is totally indiscriminate about which machines
|> it will respond to queries from. Normal NIS maps can be read by anyone
|> on the Internet who can route packets to your NIS server and back.
|> "secure" (HA!) NIS maps like passwd.adjunct can only be read if the querier
|> is using a privileged port (< 1024). This means that anyone can read your
|> "secure" maps if they can crack root on some machine on the Internet
|> and can route packets to your machine.
|>
|> The bug means that many machines on the Internet which use NIS are
|> vulnerable to having their password files stolen and run through "Crack" or
|> similar. Arguments about whether distributing Crack and fast U*ix encryption
|> algorithms was a good idea aside, every wannabe cracker now has a copy
|> of a reasonably state-of-the-art password guesser.
|>
|> As I said in my earlier post on this subject, the combination "I'm NIS
|> and I serve everyone" and easily available password guessers has already
|> led to breakins at some sites.
|>
|> This bug was reported to Sun in April 1990, and CERT has also been aware
|> of it for about the same length of time.
|>
|> I am told that the bug will be fixed in NIS+ or NIS3.0, or whatever it's
|> called this week, which I understand will be available in Solaris 2.0.
|>
|>
|> What to do about it:
|>
|> 1) The Sun Party Line. "Don't run ypserv on your gateway and disable
|>    IP forwarding on the gateway". This is commonly known as a
|>    "firewall" (provided the machine is also in other respects
|>    reasonably secure) and is probably already done by many commercial
|>    users of the Internet. It is not the greatest in convenience, and
|>    most University sysadmins would encounter, lets say, a little user
|>    resistance. Managing the gateway is also a pain.  Switching off
|>    `routed' alone, as has been suggested here, is usually insufficient.
|>    However, provided the security of the firewall is not breached, you
|>    are safe from this attack, and many others. Instructions on how
|>    to disable IP forwarding in the kernel are in Sun's Network Admin
|>    manual.
|>
|> 2) The Lamb Party Line. If you communicate to the outside world through a
|>    smart router, filter out packets coming from external connections
|>    addressed to destination ports sunrpc/udp&tcp (port 111) and ports
|>    600-1023, tcp&udp. This will prevent access to *all* sunrpc services
|>    from outside the router. It will also block access to the Kerberos
|>    protocols (probably also not a bad idea given the info. in Steve
|>    Bellovin's paper about Kerberos security problems), and will
|>    probably block the BSD `r' (rcp,rlogin, etc) commands, but don't
|>    count on it doing so.  If you and your router are smart enough, you
|>    may be able to make the `r' commands work.  Eg, for rlogin, allow
|>    the packets through iff their source is 513/tcp (this opens up a hole
|>    for a sufficiently clever cracker, though). Blocking port 111 alone
|>    is insufficient but will block the most obvious attacks (including
|>    those I've been told have already actually occurred).
|>
|> The above two solutions are the only real answers to the problem. There
|> are some workarounds which make life harder for the potential cracker.
|>
|> 1) Choose a hard-to-guess NIS domain name. The cracker must be able to guess
|>    your NIS domain name in order to talk to ypserv. This is purest security-
|>    through-obscurity. The domain name is normally only handled by
|>    automatic systems, and can be up to 64 characters long. Making the first
|>    part a reasonable handle may help system administration. Something like
|>     my-old-domainname-Ldp.T2d9wCY
|>    is probably reasonable. This precaution is vulnerable to "social
|>    engineering" attacks, ie. the cracker trying to fool a user at your site
|>    to reveal the domain name, since the NIS domain name can be discovered by
|>    any user on your machines.
|>
|> 2) Use passwd+ or npasswd to vet passwords. If you do this, you need to
|>    make all your users put their current password through the new
|>    password program. Using a premptive check on passwords for idiotic
|>    usage is a good idea anyway, independent of whether you use NIS or
|>    not.  If you have Suns and you'd rather spend money than install
|>    free software, Sun Shield (TM) also provides this capability, along
|>    with other more or less useful things.  Convex provides some similar
|>    capabilities in their passwd(1) program.  Some other manufacturers
|>    may also have similar capabilities. The more sites that do this, the more
|>    frustrating it will become for crackers trying to guess passwords.
|>
|>
|>
|> Note that this problem is common to all versions of NIS or Yellow Pages,
|> that I know of not just on Suns. It will probably go away in NIS+ aka NIS3.0,
|> but it seems that this will be a little while coming, and for non-Sun
|> machines even further off.
|>
|> Using NIS in combination with Sun's so-called `C2' security will *not* help.
|>
|> For those not aware of current technology in password guessing programs,
|> Alan Muffet (?sp) "Crack" program can test > 500 guesses/sec against
|> a U*ix encrypted password on any modern RISC workstation. This means that
|> an encrypted password can be checked against the entire /usr/dict/words
|> in less than a minute. "Crack" has been posted to the network, and you
|> can assume that most crackers and wannabe's have a copy.
|>
|>
|> Peter Lamb ([e-mail]) (depressed)
|>
|>
|> PS: Sorry, I will not respond to requests for more details about how to
|>     exploit this hole. Sun and CERT have full details. If you have a Sun
|>     s/w maintenance contract, the escalation SO# was 484666 and the Sun BugId
|>     was 1036869. Please contact Sun if you feel you need more details.

--

Alain Brossard, Ecole Polytechnique Federale de Lausanne,
    SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, [phone]
[e-mail]